Method and apparatus for cross-tier management in multi-tier computing system architecture

ABSTRACT

Techniques are disclosed for providing cross-tier management in a multi-tier computing system architecture. For example, a method for managing a computing system, wherein the computing system includes a first tier and at least a second tier, wherein the first tier and the second tier are configured to respond to a request received by the computing system, includes the steps of monitoring performance of the second tier from the first tier, and sending one or more management commands from the first tier to the second tier based on the monitored performance. In one embodiment, the first tier may be an application server tier of the computing system, and the second tier may be a database server tier of the computing system.

FIELD OF THE INVENTION

The present invention relates to computing systems, and, moreparticularly, to techniques for management of such computing systems.

BACKGROUND OF THE INVENTION

Most Internet service sites such as electronic commerce (e-commerce) websites have a multi-tier computing system architecture that partitionsthe processing of web requests into tiers or stages. Such a multi-tierarchitecture may, for example, include an edge server stage, anHypertext Transport Protocol (HTTP) server stage, an application serverstage, and a database server stage.

Management systems are typically used to monitor the performance of thecomputing system and to cause actions to be taken to address performanceproblems. However, existing management solutions employ only a one-tiermanagement approach. For example, an existing management system providesfor dynamic capacity provisioning of the application server tier.However, such an approach does not take into account more than one tierof a multi-tier architecture, nor does it take into account interactionbetween tiers such as between the application server tier and some othertier.

By way of example, a resource bottleneck can exist in a backend tiersuch as the database tier. However, since the existing management systememploys the one-tier management approach, interaction between theapplication server tier and the database server tier is not considered.Further, as a result, there is no ability provided by existingmanagement techniques to manage one tier from another tier.

Accordingly, it would be desirable to provide a management approach thatis able to take into account multiple tiers of a computing systemarchitecture, and interactions there between, by managing one or moretiers of the computing system from one or more other tiers of thecomputing system.

SUMMARY OF THE INVENTION

Principles of the invention provide a management approach that is ableto take into account multiple tiers of a computing system architecture,and interactions there between, by managing one or more tiers of thecomputing system from one or more other tiers of the computing system(i.e., provide cross-tier management).

For example, in one aspect of the invention, a method for managing acomputing system, wherein the computing system includes a first tier andat least a second tier, wherein the first tier and the second tier areconfigured to respond to a request received by the computing system,includes the steps of monitoring performance of the second tier from thefirst tier, and sending one or more management commands from the firsttier to the second tier based on the monitored performance.

The first tier may be an application server tier of the computingsystem, and the second tier may be a database server tier of thecomputing system.

The second tier may include a node agent for receiving the one or moremanagement commands such that management control in the first tierextends to the second tier. The second tier may include an interface forabstracting the one or more management commands with respect to one ormore provider-specific database management plug-in modules. The firsttier and the second tier may implement a management model including amanageability extension layer, a manageability abstraction layer and amanaged resource layer.

In a second aspect of the invention, a method for managing a computingsystem, wherein the computing system includes a first tier and at leasta second tier, wherein the first tier and the second tier are configuredto respond to a request received by the computing system, includes thesteps of sending performance data from the second tier to the firsttier, and receiving one or more management commands from the first tierat the second tier based on the monitored performance.

In a third aspect of the invention, apparatus for managing a computingsystem, wherein the computing system includes a first tier and at leasta second tier, wherein the first tier and the second tier are configuredto respond to a request received by the computing system, comprises: anode agent at the second tier configured to: (i) send performance datafrom the second tier to the first tier; and (ii) receive one or moremanagement commands from the first tier at the second tier based on themonitored performance; and an interface at the second tier configured toabstract the one or more management commands with respect to one or moreprovider-specific database management plug-in modules.

In a fourth aspect of the invention, a method for managing one or moregoals in a system that includes two or more tiers, whereby workprogressively flows from tier-to-tier of the system, includes the stepsof communicating one or more directives from a higher-level tier to alower-level tier, and converting the one or more directives at thelower-level tier into instructions executable by a management componentspecific to the lower-level tier so as to effect the one or more systemgoals.

For example, work may progressively flow from a first tier to a secondtier and subsequently from the second tier to at least a third tier.Accordingly, the communicating step and the converting step may furtherinclude communicating one or more directives from the first tier to thesecond tier, converting the one or more directives at the second tierinto instructions executable by a management component specific to thesecond tier, communicating one or more directives from the second tierto the third tier, and converting the one or more directives at thethird tier into instructions executable by a management componentspecific to the third tier.

In a fifth aspect of the invention, a system for providing cross-tiermanagement of resources in a computer system includes the followinglayers. A manageability extension layer includes node agent code on amanaged resource tier for receiving one or more control andconfiguration commands for the managed resource from an applicationserver tier. A manageability abstraction layer includes code forinteracting with a management interface and thereby defining a serviceprovider interface for abstracting the one or more control andconfiguration commands. A managed resource layer includesresource-specific code for controlling a managed resource within themanaged resource layer.

Advantageously, management principles of the invention may considerinteraction between different tiers of the computing systemarchitecture. Furthermore, principles of the invention may also providethe ability to change resource configurations across multiple tiers.

These and other objects, features and advantages of the presentinvention will become apparent from the following detailed descriptionof illustrative embodiments thereof, which is to be read in connectionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a multi-tier computing system architecture in whichcross-tier management techniques may be implemented, according to anembodiment of the invention.

FIG. 2A illustrates a cross-tier management model, according to anembodiment of the invention.

FIG. 2B illustrates a cross-tier management methodology for managing adatabase tier from an application server tier, according to anembodiment of the invention.

FIG. 3 illustrates a computer system wherein cross-tier managementtechniques may be implemented, according to an embodiment of theinvention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

It is to be understood that the present invention is not limited to anyparticular multi-tier computing system architecture. Rather, theinvention is more generally applicable to any multi-tier computingsystem architecture in which it would be desirable to provide amanagement approach that is able to manage one or more tiers of thecomputing system from one or more other tiers of the computing system.

Before describing management techniques of the invention, we provide ageneral description of an illustrative multi-tier computing systemarchitecture.

FIG. 1 depicts such a multi-tier computing system architecture. Eachtier comprises one or more nodes (e.g., hardware entities) that arededicated to a specific kind of processing. In architecture 100 depictedin FIG. 1, the first tier or edge server tier 102 provides loadbalancing and request routing. The second tier or HTTP server tier 104performs HTTP parsing and response generation. The third tier 106contains application servers typically providing a Java 2 PlatformEnterprise Edition (J2EE) for business logic (e.g., the software used toexecute the particular e-commerce application). The fourth tier 108contains database server nodes that manage persistent data. Thearchitecture may include a fifth tier (not shown) as well, if a separatestorage system is used (e.g., a storage area network).

In general, client requests enter the first tier and are routed to anHTTP server. Some fractions of the HTTP requests also require processingby application servers. A fraction of the requests processed byapplication servers also require services from a database server.Because inter-tier interaction is synchronous, threads/processes inupstream tiers are blocked while waiting for the completion ofprocessing in downstream tiers. Thus, requests may simultaneouslyconsume resources in the HTTP, application, and database server nodes.After processing by some or all of the tiers of the multi-tier computingsystem, a response to the request is sent to the client.

Principles of the invention provide techniques for enabling cross-tiermanagement of resources in a multi-tier computing system. It is to beunderstood that principles of the invention identify a managed tier(e.g., database tier 108 in FIG. 1) and a managing tier (e.g.,application server tier 106 in FIG. 1).

Management techniques of the invention employ a multi-layer managementmodel. In one embodiment, as illustrated in FIG. 2A, such model 200includes a manageability extension layer 202, a manageabilityabstraction layer 204, and a managed resource layer 206.

As will be illustrated below in the context of FIG. 2B, themanageability extension layer includes node agent software code thatresides on a managed resource tier for receiving control andconfiguration commands for a managed resource from an application servertier (managing tier). The manageability abstraction layer includessoftware code for interacting with a management interface and therebydefining a service provider interface (SPI). The managed resource layerincludes resource-specific software code for controlling a managedresource within the managed resource layer.

In one embodiment, the node agent code on the managed resource tierincludes performance reporting code for sending performance informationregarding the managed resource back to the application server tier.While the invention is not limited to any particular managementenvironment, it is particularly well suited for use in a WebSphere™Deployment Management environment (IBM Corporation of Armonk, N.Y.).

In accordance with a WebSphere™ environment, principles of the inventionprovide a cross-tier workload management methodology that is Javaapplication server centric. For ease of explaining the concepts, we usea WebSphere™ application server (WAS) as the application tier and DB2™(IBM Corporation of Armonk, N.Y.) as the backend tier. However, theconcepts introduced herein can be easily applied to other applicationservers and other backend tiers.

FIG. 2B illustrates a cross-tier management methodology according to anembodiment of the invention. In the context of FIG. 2B, we illustratehow model 200 can be applied to controlling a database server tier froman application server tier. The controlling entity is WebSphere™Application Server (WAS) tier and the backend controlled tier is adatabase tier.

As shown, an extended WebSphere™ cell 210 includes an on demand router212, an application server cluster 214 including WAS nodes 1, 2 and 3with respective node agents 215-1, 215-2, and 215-3, administratorconsole 216, client 218, and deployment manager 220. Cell 210 alsoincludes managed database (DB) node 222 including database 1, database2, DB controller 224, plug-in SPI 226, node agent 228, operating system230, and plug-ins 232.

In general, a request enters the cell at router 212 and is routed to aparticular WAS node in the server cluster 214. The WAS node that handlesthe request may be selected based on the priority of the request (e.g.,high priority requests going to WAS nodes 1 or, and low priorityrequests going to WAS node 3). Depending on the nature of the request,the WAS node may require assistance of a database server node (e.g.,Database 1 or Database 2) in order to respond to the request. Again, thedatabase server node may be selected based on the priority associatedwith the request.

Typically, WebSphere™ node agents (i.e., 215-1 through 215-3) are usedas management (configuration and control) servers between WAS nodes andthe WebSphere™ deployment manager 220 in a WebSphere extended deploymentor network deployment setup. Note that block 216 is a user interfacewhere a system administrator sets management goals and parameters. Block218 represents software code that executes management functions.

In accordance with illustrative principles of the invention, theWebSphere™ node agent is extended for other non-application tiers (e.g.,the managed DB tier, the storage systems, etc.). Such extension isrealized in cell 210 of FIG. 2B by node agent 228, located in managed DBnode 222. This is considered the manageability extension layer (202 ofFIG. 2A) of the cross-tier management model of the invention.

It is to be understood that while FIG. 2B illustrates the applicationserver (WAS) tier managing the database (DB) tier, we can place nodeagents in other tiers with non-identical functions to facilitatedistributed administration and workload management beyond WAS instances.For example, besides the WAS tier and the DB tier, suppose we have athird tier, e.g., a storage tier, as well. Hence, the managementinfrastructure is as follows. WAS is the managing server with respect toDB, the managed resource, and thus WAS puts agent code in the DB tier.Similarly, DB is the managing server with respect to storage, themanaged resource, and thus DB puts agent code in the storage tier.

Returning to the embodiment of FIG. 2B, the placement of node agent 228on the database node 222 allows the database to be managed from theapplication server tier. This node agent 228 can receive any control andconfiguration commands for different databases thereon from theapplication tier via deployment manager 220. Node agent 228 can alsosend back any performance related information of the databases back tothe application tier.

The management extensions to the node agent provide an abstractinterface, to a controlling entity such as the WebSphere™ Deploymentmanager 220, independent of the underlying virtualization technologiessuch as OS WLM (e.g., Linux CKRM, AIX WLM, HP-UX WLM, Solaris ResourceManager) and partitioning technologies such as dynamic LPAR, Linux Xen,Meiosys Metacluster, etc. CKRM refers to class-based kernel resourcemanagement (http://ckrm.sourceforge.net/), AIX WLM refers to a workloadmanagement system (http://www.redbooks.ibm.com/abstracts/sg245977.html),dynamic LPAR refers to dynamic logical partitions(http://www-03.ibm.com/servers/eserver/iseries/lpar/) and Linux Xen isdescribed at http://kerneltrap.org/node/4168. These are only examples ofplug-ins that may be used in the WebSphere™ cell.

The implementation of this interface may be based on open standards suchas Java Management Extensions or Web Services Distributed Management(WS-DM).

As shown in FIG. 2B, DB controller 224 provides abstraction fromplatform specific workload management capability. This is considered themanageability abstraction layer (204 of FIG. 2A) of the cross-tiermanagement model of the invention. DB controller 224 defines a ServiceProvider Interface (SPI) 226 that is implemented by the managed resourcelayer (206 of FIG. 2A). The manageability abstraction layer contains thelogic to interact with any management infrastructure such as JMX orWS-DM. JMX: Java Management Extensions are described athttp://java.sun.com/products/JavaManagement/, and WS-DM: Web ServicesDistributed Management is described at(www.oasis-open.org/committees/wsdm/).

In the case of WebSphere, the preferred management protocol is JMX. Thislayer also has the processing capability to determine which plug-in ofthe managed resource layer has to be invoked to achieve control.

Furthermore, the abstraction layer is the layer that serves to hide theimplementation details of the resource so that an entity (e.g., systemadministrator or processing node) that requests some action need onlyrequest the action without needing to know how the action isaccomplished. For example, if an entity wants to increase the CPU share10% for an application, it only needs to issue a generic command such as“increase CPU 10%.” The abstraction layer translates this command intoan executable command according to the respective grammar understood bythe different resources, i.e., since the actual command for plug-inLinux CKRM would be different than the actual command for plug-in AIXWLM.

The managed resource layer contains the implementation of technologyspecific “glue code” to provide the actual control logic (the glue coderefers to the actual command understood by the plug-in). That is, themanaged layer contains the resource specific logic to implement theactual control. In FIG. 2B, plug-ins 232 define this layer. The controlof the DB tier resources (230) can be achieved using various optionssuch as Linux CKRM, AIX WLM, dynamic LPAR, or DB2 WLM.

An example of configuration and control could be creating classes forthe various database instances in the OS WLM and then creating rules forclassifying the processes belonging to these instances into the properclass and applying the proper amount of resource (CPU, IO, memory)shares to the classes based on a request from the controlling entity.

Again, it is to be understood that while FIG. 2B illustrates managementof a second tier (database server tier) from a first tier (applicationserver tier), the management model of FIG. 2A may be applied to three ormore tiers of a computing system. That is, principles of the inventionmay be used to manage end-to-end goals in a system that includes threeor more tiers whereby work progressively flows from a first tier to asecond tier and subsequently from the second tier to the third tier, andso on to other subsequent tiers. For example, the first tier manages thesecond tier and the second tier manages the third tier and so on. Suchtier-to-tier management is achieved by employing management translationlayers that allow the higher-level tier to communicate directives(commands) to the lower-level tier. The lower level tierconverts/accepts these directives into its own/native managementcapability.

FIG. 3 is a block diagram illustrating an illustrative hardwareimplementation of a computer system in accordance with which one or morecomponents/steps of a management system (e.g., components/stepsdescribed in the context of FIGS. 1, 2A, and 2B) may be implemented,according to an embodiment of the present invention. For example, theillustrative architecture of FIG. 3 may be used in implementing any andall of the components (i.e., nodes, node agents, database servers,deployment manager, DB controller, plug-ins, etc.) of any of the tiersshown in FIGS. 1, 2A, and 2B.

Further, it is to be understood that the individual components/steps maybe implemented on one such computer system, or more preferably, on morethan one such computer system. In the case of an implementation on adistributed system, the individual computer systems and/or devices maybe connected via a suitable network, e.g., the Internet or World WideWeb. However, the system may be realized via private or local networks.The invention is not limited to any particular network.

As shown, the computer system 300 may be implemented in accordance witha processor 302, a memory 304, I/O devices 306, and a network interface308, coupled via a computer bus 310 or alternate connection arrangement.

It is to be appreciated that the term “processor” as used herein isintended to include any processing device, such as, for example, onethat includes a CPU (central processing unit) and/or other processingcircuitry. It is also to be understood that the term “processor” mayrefer to more than one processing device and that various elementsassociated with a processing device may be shared by other processingdevices.

The term “memory” as used herein is intended to include memoryassociated with a processor or CPU, such as, for example, RAM, ROM, afixed memory device (e.g., hard drive), a removable memory device (e.g.,diskette), flash memory, etc.

In addition, the phrase “input/output devices” or “I/O devices” as usedherein is intended to include, for example, one or more input devices(e.g., keyboard, mouse, etc.) for entering data to the processing unit,and/or one or more output devices (e.g., speaker, display, etc.) forpresenting results associated with the processing unit.

Still further, the phrase “network interface” as used herein is intendedto include, for example, one or more transceivers to permit the computersystem to communicate with another computer system via an appropriatecommunications protocol.

Accordingly, software components including instructions or code forperforming the methodologies described herein may be stored in one ormore of the associated memory devices (e.g., ROM, fixed or removablememory) and, when ready to be utilized, loaded in part or in whole(e.g., into RAM) and executed by a CPU.

It is to be further appreciated that the present invention alsocomprises techniques for providing cross-tier management services.

By way of example, a service provider agrees (e.g., via a service levelagreement or some informal agreement or arrangement) with a servicecustomer to provide cross-tier management services. That is, by way ofone example only, the service provider may host the customer's web siteand associated applications (e.g., e-commerce applications). Then, inaccordance with terms of the contract between the service provider andthe service customer, the service provider provides cross-tiermanagement services which may comprise one or more of the methodologiesof the invention described herein.

Although illustrative embodiments of the present invention have beendescribed herein with reference to the accompanying drawings, it is tobe understood that the invention is not limited to those preciseembodiments, and that various other changes and modifications may bemade by one skilled in the art without departing from the scope orspirit of the invention.

1. A method for managing a computing system, wherein the computingsystem comprises a first tier and at least a second tier, wherein thefirst tier and the second tier are configured to respond to a requestreceived by the computing system, the method comprising the steps of:monitoring performance of the second tier from the first tier; andsending one or more management commands from the first tier to thesecond tier based on the monitored performance.
 2. The method of claim1, wherein the first tier comprises an application server tier of thecomputing system.
 3. The method of claim 1, wherein the second tiercomprises a database server tier of the computing system.
 4. The methodof claim 1, wherein the second tier comprises a node agent for receivingthe one or more management commands such that management control in thefirst tier extends to the second tier.
 5. The method of claim 1, whereinthe second tier comprises an interface for abstracting the one or moremanagement commands with respect to one or more provider-specificdatabase management plug-in modules.
 6. The method of claim 1, whereinthe first tier and the second tier implement a management modelcomprising a manageability extension layer, a manageability abstractionlayer and a managed resource layer.
 7. A method for managing a computingsystem, wherein the computing system comprises a first tier and at leasta second tier, wherein the first tier and the second tier are configuredto respond to a request received by the computing system, the methodcomprising the steps of: sending performance data from the second tierto the first tier; and receiving one or more management commands fromthe first tier at the second tier based on the monitored performance. 8.The method of claim 7, wherein the first tier comprises an applicationserver tier of the computing system.
 9. The method of claim 7, whereinthe second tier comprises a database server tier of the computingsystem.
 10. The method of claim 7, wherein the second tier comprises anode agent for receiving the one or more management commands such thatmanagement control in the first tier extends to the second tier.
 11. Themethod of claim 7, wherein the second tier comprises an interface forabstracting the one or more management commands with respect to one ormore provider-specific database management plug-in modules.
 12. Themethod of claim 7, wherein the first tier and the second tier implementa management model comprising a manageability extension layer, amanageability abstraction layer and a managed resource layer. 13.Apparatus for managing a computing system, wherein the computing systemcomprises a first tier and at least a second tier, wherein the firsttier and the second tier are configured to respond to a request receivedby the computing system; the apparatus comprising: a node agent at thesecond tier configured to: (i) send performance data from the secondtier to the first tier; and (ii) receive one or more management commandsfrom the first tier at the second tier based on the monitoredperformance; and an interface at the second tier configured to abstractthe one or more management commands with respect to one or moreprovider-specific database management plug-in modules.
 14. The apparatusof claim 13, wherein the first tier comprises an application server tierof the computing system.
 15. The apparatus of claim 13, wherein thesecond tier comprises a database server tier of the computing system.16. A method for managing one or more goals in a system that comprisestwo or more tiers, whereby work progressively flows from tier-to-tier ofthe system, the method comprising the steps of: communicating one ormore directives from a higher-level tier to a lower-level tier; andconverting the one or more directives at the lower-level tier intoinstructions executable by a management component specific to thelower-level tier so as to effect the one or more system goals.
 17. Themethod of claim 16, wherein work progressively flows from a first tierto a second tier and subsequently from the second tier to at least athird tier.
 18. The method of claim 17, wherein the communicating stepand the converting step further comprise: communicating one or moredirectives from the first tier to the second tier; and converting theone or more directives at the second tier into instructions executableby a management component specific to the second tier.
 19. The method ofclaim 18, wherein the communicating step and the converting step furthercomprise: communicating one or more directives from the second tier tothe third tier; and converting the one or more directives at the thirdtier into instructions executable by a management component specific tothe third tier.
 20. A system for providing cross-tier management ofresources in a computer system, comprising: a manageability extensionlayer comprising node agent code on a managed resource tier forreceiving one or more control and configuration commands for the managedresource from an application server tier; a manageability abstractionlayer comprising code for interacting with a management interface andthereby defining a service provider interface for abstracting the one ormore control and configuration commands; and a managed resource layercomprising resource-specific code for controlling a managed resourcewithin the managed resource layer.